FIG. 1 is an illustration of conventional P2P network 100. Network 100 includes source peer 101, receiving peers 102-108, and tracker server 110. In one example, receiving peer 108 is joining network 110 and begins the process by requesting information from tracker server 110. Specifically, peer 108 asks tracker server 110 for a list of neighboring peers that are sharing a particular stream, which source peer 101 provides. The list of neighboring peers generally includes other peer devices in P2P network 100 and may include some or all of peers 101-107.
Once receiving peer 108 receives the list of neighboring peers, it requests buffer maps from those neighboring peers. A buffer map is a set of data that generally conforms to the following format: <buffer offset, play offset, bitmap>. A given peer's buffer can generally be thought of as a memory that stores the received portions of the stream. The portions are numbered sequentially, and a portion's number serves as its identifier. A peer will typically request and save portions of the stream for some amount of time before the portions are played in order to provide a smooth and continuous playback for the user. The buffer also will typically keep portions of the stream that have been played for a certain amount of time in case other peers request the played portions. As additional portions are received, older portions can be dropped.
FIG. 2 is a conceptual representation of buffer map 200, which may be used by peers in conventional P2P network 100. For example, peer 108 may receive buffer map 200 from peer 102. When received, buffer map 200 takes the form <80,84, 1111 1111 0000 1010>. As shown, the buffer offset is 80, which identifies the portion of the stream where the buffer begins (i.e., the earliest-in-time portion that is currently buffered by the peer that sent buffer map 200). The playback offset is 84, which identifies the portion currently playing by the peer that sent buffer map 200. Bitmap 201 is a set of ones and zeros where a one indicates that the particular portion of the stream is currently buffered, and a zero indicates that the particular portion has not been received.
Returning to FIG. 1, peer 108 requests buffer maps from its neighboring peers and receives buffer maps in the format described above. It is generally expected that various peers receiving the same stream have varying buffer maps with different buffer offsets, play offsets, and bitmaps. Peer 108 “knows” which portions of the stream are available from each of its neighbors by examining the contents of the received buffer maps. Peer 108 then begins requesting portions of the stream from one or more of its neighboring peers and creating its own buffer.
An issue that arises in P2P network 100 is that if peer 108 begins requesting the stream beginning at the very latest portions, it may send many requests to source peer 101, thereby overloading source peer 101. On the other hand, if peer 108 begins requesting the stream at portions that are older, then the viewer of peer 108 sees a significantly time-delayed version of the stream (which may be unappealing for some live streams, such as for sports events). There is currently no satisfactory technique for selecting a starting offset for a peer device in a P2P network.